Release 10.1A: OpenEdge Getting Started:
Object-oriented Programming

Using polymorphism with classes

Polymorphism is one of the most powerful advantages of object-oriented programming. Multiple classes that inherit from the same super class can override the behavior in the super class and provide unique implementations for the methods defined in the super class. This allows each subclass to express a different behavior in response to the same method. Polymorphism, then, allows invocations of the method on a super class object reference to be dispatched to the overriding method in the instantiated subclass at run time.

In the following class examples, ShapeClass is extended by both CircleClass and RectangleClass. The super class ShapeClass defines a method CalculateArea, as shown:

CLASS ShapeClass:     METHOD PUBLIC DECIMAL CalculateArea ( ):         /* Dummy routine */         MESSAGE "If you got here someone did not override this method!"             VIEW-AS ALERT-BOX.     END METHOD. END CLASS.

Both RectangleClass and CircleClass also define a CalculateArea method. The RectangleClass uses the length and width, as shown:

CLASS RectangleClass INHERITS ShapeClass:     DEFINE PRIVATE VARIABLE length AS DECIMAL NO-UNDO.     DEFINE PRIVATE VARIABLE width AS DECIMAL NO-UNDO.     CONSTRUCTOR PUBLIC RectangleClass                            (INPUT l AS DECIMAL, INPUT w AS DECIMAL):         length = l.         width = w.     END CONSTRUCTOR.     METHOD PUBLIC OVERRIDE DECIMAL CalculateArea ( ):         RETURN length * width.     END METHOD. END CLASS.

The CircleClass needs the radius only, as shown:

CLASS CircleClass INHERITS ShapeClass:     DEFINE PRIVATE VARIABLE radius AS DECIMAL NO-UNDO.     DEFINE PRIVATE VARIABLE pi AS DECIMAL INITIAL 3.14159 NO-UNDO.     CONSTRUCTOR PUBLIC ShapeClass (INPUT r AS DECIMAL):         radius = r.     END CONSTRUCTOR.     METHOD PUBLIC OVERRIDE DECIMAL CalculateArea ( ):         RETURN pi * radius * radius.     END METHOD. END CLASS.

The following Main class demonstrates the polymorphic behavior of these classes:

CLASS Main:     DEFINE VARIABLE rShape1 AS CLASS ShapeClass NO-UNDO.     DEFINE VARIABLE rShape2 AS CLASS ShapeClass NO-UNDO.     DEFINE VARIABLE width AS DECIMAL NO-UNDO INITIAL 10.0.     DEFINE VARIABLE length AS DECIMAL NO-UNDO INITIAL 5.0.     DEFINE VARIABLE radius AS DECIMAL NO-UNDO INITIAL 100.0.     CONSTRUCTOR PUBLIC Main ( ):         rShape1 = NEW RectangleClass( INPUT width, INPUT length).         rShape2 = NEW CircleClass (INPUT radius).         MESSAGE rShape1:CalculateArea( ) VIEW-AS ALERT-BOX.         MESSAGE rShape2:CalculateArea( ) VIEW-AS ALERT-BOX.     END CONSTRUCTOR. END CLASS.

Note that the first two definitions define rShape1 and rShape2 variables that are references to ShapeClass. This way, they can be used to reference any instantiated shape. When each ShapeClass instance is created, the specific shape type is specified in the NEW statement to specialize the general ShapeClass type. This means that while only methods defined in ShapeClass can be invoked with these object references, the implementation that is executed depends on the actual class instance that the ShapeClass object reference is pointing to.

Thus, CalculateArea( ) is defined in ShapeClass, so it can be invoked on both references. But because of the polymorphic relationship to the specialized subclasses that are instantiated, the version of CalculateArea( ) that is run in each case is the version in RectangleClass and CircleClass, respectively.

So, the use of polymorphism depends on the principle that a general domain exists over which a set of common operations can be applied and tailored to suit the requirements of more specialized subsets of that domain. In the previous example, the general domain is the domain of shapes and each specialized domain consists of different types of shapes, such as rectangles and circles. The subclass for each of these specialized shapes implements the same common set of operations to suit the requirements of its own specialized domain subset.

In the larger domain of business applications, one can similarly imagine many different uses for polymorphism. For example, in a general ledger system, you might have a super class for the domain of general accounts that provides a set of methods that operate on all accounts. You might then have one subclass representing asset accounts and another subclass representing liability accounts that both inherit from the general accounts class. In a general ledger system, some of the same methods inherited from the general accounts class would function as inverses of each other as implemented in the liability accounts class or the asset accounts class.

You might then create even more specialized subclasses that inherit from the asset accounts or liability accounts class. So, for example, in a hospital system, you might create a subclass of employee accounts that inherits from the liability accounts class and a subclass of patient accounts that inherits from the asset accounts class. Of course, there are many additional accounts that might be represented as subclasses of either the liability or asset accounts class in such a system.

Thus, by understanding the domain of a business environment and the specific problem that an application is intended to solve, you can virtually always represent the solution in terms of these polymorphic relationships between more general and more specialized domains. And you can likely implement any of the problem solutions for these domains using classes in the Progress 4GL.